Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 083 / phnxdoc.arc / PHNXDOC.7 < prev next >

Wrap

Text File | 1987-12-04 | 12.6 KB | 264 lines

PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 7.0 PHOENIX NETWORKING Before we get started talking about how Phoenix handles its network system, we must give you a little history about this process. First, this whole network concept was dreamed up by a man named Tom Jennings, who, among other things, is responsible for a bulletin board program called "FIDO". Tom had a wonderful idea of connecting these bulletin boards together at a predetermined time to send mail, or packets, to each other. We thought enough of Tom's idea to include his FIDONET concept in Phoenix. NOTE: At present, Phoenix and Fido are NOT fully compatable. 7.1 NET-MAIL DESCRIPTION (NOTE: Many of the following notes were taken out of Tom Jennings's "FIDO'S Complete Operating Manual".) The purpose of this net mail concept is to link Phoenix Bulletin Board systems together for automatic message transfers. This Net system is a true dial up packet switch network system that supports many different topologies. It supports routing, message forwarding, scheduling and uses a tuned collision detection algorithm over normal phone lines, for the lowest possible cost and highest efficiency. The simplest scheme, and the one to set initially, supports point-to-point messages. Most major geographical area have a host that will accept mail for itself and its local nodes. After you have contacted any other Phoenix sysops in your area, you can tie into their local network, and take advantage of the lower cost. Each local area runs things differently, and their policies cannot be covered here. If you can't find your local region or host, contact Phoenix 800/1 at 316-788-3630, where you can find the latest node list and other files to help steer you in the right direction. The original FidoNET design was built around the current Bulletin Board architecture which is basically: an unknown number of completely independent, stand alone systems, with extremely low overhead in both maintenance and cost. The Phoenix Net System was designed to be compatible with this, in that it should involve: 1. No extra work for the SysOp. 2. No effect on normal BBS operations. 3. No unexpected extra costs. 4. No effect upon system reliability. Phoenix handles this automatically, and requires no extra work, once set up. Other than the effect of allowing Network-wide message traffic, the only other affect upon the current BBS is that it is "down" to normal traffic (regular callers) during the National net time of 1am to 2am PST (4am to 5am EST). Please be sure to correctly figure your time zone. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 Costs, if any, are controlled by the sysops. Unless specifically enabled, mail will not be sent out from a node. Remember, sending mail costs money; receiving packets is free. Phoenix provides accounting and cost limitation functions (all automatic) to prevent unauthorized mail from being sent. There can also be "free" traffic to non-toll call nodes as well as limitations put on long distant calls. The usual privilege levels can be applied to each of the mail commands, to control their use. Net-mail success/failure does not in anyway affect BBS operations. Failure to make a connection and transmit a packet, or errors during incoming packets, affect only the mail sent or received. In the case of transmission, the message will not be sent, nor will charges (if any) be applied to the sender's credit account. For a paying system, the sysop must occasionally set the user's credit, using the "Utilities for the SysOp" section and crediting the user's account. If reasonably large sums are used as a minimum ($5.00 or more), this will not need to be done more than once every few weeks. 7.2 GETTING A NET/NODE NUMBER In order to obtain a Phoenix net/node number and join in the PhoenixNet, you must have had your Phoenix board running for at least 1 week. During this time you should set your Net/Node number to 800/999 (that is Net 800, Node 999). Do this in CONFIG. This indicates that you are awaiting a net/node number. With this temporary net/node number set, you must send a NetMail message (so we know you are indeed running the Net) to Bennett Griffin at 800/1 (The Aztec BBS) with the following information: Sysop Name Board Name Data Number Sysop Home Number Board Location Time Zone Sysop Age After you have sent this information to 800/1, it will be processed and you will be issued a Net/Node number. You will be notified of your net/node number and you will then be added to the nodelist. If you haven't received your net/node number within a week, inquire at 800/1 as to why and we'll check on it (we stay pretty busy!). Note: Applictaions MUST be sent through NetMail... All others will NOT be processed. Also, applications must be sent with a net/node number of 800/999. 'Self-assigned' node numbers will NOT be processed at all. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 7.3 HOW IS THE NET/NODE SYSTEM ORGANIZED? After trying to analyze why people use the Net-Mail feature of Phoenix we came up with one common reason: "Location". More than any other reason, callers use the system because they want to contact a person in a certain area of the country. For this reason, Nets will be assigned by State. Note, the Phoenix Development/GeneSys Project Sites are all listed in Net 800. This is so you have easy access to the one closest to you for help and assistance, and, should the need arise, a place to report the ugly bugs! (YUCK.)! Nodes are Systems within each net. Each Net can hold up to 32767 nodes before we have to open another Net number. 7.4 NET-MAIL OPERATION Within Phoenix is the Net-Mail module which is run as specified by the scheduler. This module is a time driven system, and the national time slot is at 1:00 AM Pacific Standard Time, 4:00 AM for you on the east coast. During normal Phoenix operation, users can enter messages, and, during the Net-Mail time, these messages are made into packets and sent to the right destination. The messages may be destined to any one or more of the available remote nodes in the nodelist. At the predetermined time, the Net-Mail module takes control. Within 5 minutes of the scheduled event Phoenix will automatically drop DTR so users do not get on the system. If a user is on the system, Phoenix will inform them of the upcoming scheduled event and give them a chance to log-off, or, if needed, Phoenix will log them off just as if they exceeded their time limit. The Net-Mail module then (if enabled) creates mail packets, one per node, containing the messages for each node. If there is no mail to a node, no packet is created, and no call is made to that system. After the outgoing packets are made, Phoenix alternately waits for calls and attempts to place calls. Mail packet transfers are done on a collision detection basis. After the first few collisions, the network synchronizes. If there are a number of nodes to send mail to, each one is called in turn, until all are sent, or mail time is over. If it fails with one node, it goes on to the next, and repeats the failed one only after trying all of the others first. In between outgoing calls (if any) Phoenix delays a random interval, during which it waits for incoming calls. This interval, along with the redial algorithm, synchronizes the net after the initial collisions. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 If an incoming call is detected, it attempts connection with it. The baud rate is determined (same as for a normal caller in Phoenix), a message to human callers is displayed (warning them that the board is accepting only other Phoenix or Fido Nodes), and a synchronization process is started. This process must complete within 60 seconds, or the call is terminated. Once synchronized, the packet transfer is made. The receiver just stores that packet for later use, and then disconnects. Whenever an incoming call is received, Phoenix calls out immediately afterwards (assuming there are calls to be made), since there is a high probability that the line is now clear. This helps synchronize the network. To place an outgoing call, the sender dials the number, performs the sync process mentioned above, and transfers its outgoing packet. (Messages to a given node are again checked against the node list at mail time; if they do not match, the packet is not sent, and an error is logged.) If the transfer was successful, the destination node number is deleted from the sender's list of nodes to call. The collision detect algorithm is optimized such that during the first few minutes of mail time, there are many collisions, after which the net synchronizes, and none or few collisions occur. When mail time is over, Phoenix deletes all its outgoing packets that were assembled, and for each one that was sent successfully, marks those messages (in the mail area) as SENT, so the originator can tell if they went out or not. Then, the incoming packets are unassembled, and the messages placed sequentially in the mail area. These packets are then deleted. If any mail at all was sent, the user credits are balanced. This is somewhat unsatisfactory, as it balances the accounts even if the mail was not sent. This is to prevent extremely long processing time necessary to account for each message and user. (Users lists run upwards of 600 entries typically; on a floppy- based system, this would become unworkable.) Net-Mail then terminates, and invokes Phoenix for another day. Messages received are then accessible like any other message and placed in the message area marked for Net-Mail. All of your Net Activities are recorded in a file called "MAILER.LOG" which can be viewed with any listing type program, by using the DOS command TYPE, or by placing the filename in a dumpfile class menu call (the best way). WATCH FOR A TOTALLY NEW AND ADVANCED ELECTRONIC MAIL SYSTEM IN Phoenix v3.0. It will have features most have only dreamed about.